System and method for data recovery

ABSTRACT

A system and method for data escrow cryptography are described. An encrypting user encrypts a message using a secret storage key (KS) and attaches a data recovery field (DRF), including an access rule index (ARI) and KS, to the encrypted message. The DRF and the encrypted message are stored in a storage device. To recover KS, a decrypting user extracts and sends the DRF to a data recovery center (DRC) that issues a challenge based on access rules (ARs) originally defined by the encrypting user. If the decrypting user meets the challenge, the DRC sends KS in a message to the decrypting user. Generally, KS need not be an encryption key but could represent any piece of confidential information that can fit inside the DRF. In all cases, the DRC limits access to decrypting users who can meet the challenge defined in either the ARs defined by the encrypting user or the ARs defined for override access.

This is a continuation of application Ser. No. 08/781,626, filed Jan.10, 1997, now U.S. Pat. No. 5,965,573, which is a file wrappercontinuation of application Ser. No. 08/691,564, filed Aug. 2, 1996,abandoned, which is a divisional of application Ser. No. 08/390,959,filed Feb. 21, 1995, now U.S. Pat. No. 5,557,765, which is acontinuation-in-part of application Ser. No. 08/289,602, filed Aug. 11,1994, now U.S. Pat. No. 5,557,346.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to data encryption, and moreparticularly to key escrow data encryption.

2. Related Art

Introduction

An United States Presidential announcement on Apr. 16, 1993, referred toas the "Clipper initiative," called for the development of a hardwareimplementation of a classified encryption algorithm called "Skipjack".The Presidential announcement characterized the Skipjack algorithm asbeing "significantly stronger than those currently available to thepublic." The hardware implementation of Skipjack would also include acapability called "key escrow" which allows the government to recoverthe keys used for data encryption. The integrated circuit chip whichimplements the Skipjack algorithm is called the "Clipper chip" and/orthe "Capstone chip".

The Clipper initiative (particularly the key escrow feature) attempts topreserve the ability of law enforcement and national security tointercept and exploit the contents of communications while providinglaw-abiding citizens with an encryption system much stronger than anynow available to them. The announcement of the Clipper initiative andthe subsequent discussions made it clear that, while Skipjack is astronger encryption algorithm than the current unclassified DataEncryption Standard (DES), law enforcement entities considered that theproliferation of DES voice security devices would be a significantimpediment to their need to preserve the ability to accomplishcourt-ordered wiretaps.

A great deal of resistance to the Clipper initiative was evident in thepublic reaction to the April 16 announcement. Objections were expressedin various forms, but the following key points stand out:

Many people objected to the potential for loss of privacy that wouldresult from the deployment of key escrow cryptography and the associatedsharing of heretofore private cryptographic keys with government escrowagents.

Many people raised objections to the Administration's attempt to use thebuying power of the government to impose as de facto standards a familyof encryption products that could be defeated at will by governmentagencies.

Some people objected to the introduction of a classified algorithm asthe standard for the protection of unclassified information. DES ispublic and has had wide scrutiny in its fifteen year life. There weresuggestions that Skipjack might have a defect or trap door (other thanthe key escrow process). These objections were not quieted by thefavorable review of Skipjack by a panel of outside cryptographers.

Many people (especially suppliers of Information Technology products)objected to the requirement for a hardware implementation because of itscost and because of the limitations that the need to accommodate agovernment-designed chip imposes on overall system or product design.

In August 1993, the National Institute of Standards and Technology(NIST) announced a cooperative program with industry to explore possibleapproaches to the implementation of key escrow in software (without theneed for dedicated hardware components such as the Clipper or Capstonechips).

There are a number of issues that intertwine in any discussion of thistopic. Such issues include hardware implementation, classifiedencryption algorithms, and how much trust one must put in the user ofthe encryption process. These issues are considered below. However,before addressing these issues, it will be useful to consider keyescrow.

Key Escrow Cryptogmphy

Key escrow adds to products that implement cryptography features thatallow authorized parties to retrieve the keys for encryptedcommunications and then decrypt the communications using such keys. Inthe Clipper initiative, keys for each encryption device aremathematically divided into two halves (each equal in length to theoriginal key) and the halves are held by two separate escrow agents.Both escrow agents must cooperate (to regenerate the original key)before the communications from a given device can be decrypted. ForClipper, the escrow agents are government agencies who require assurancethat the law enforcement agency requesting the keys has a court orderauthorizing a wiretap for the communications in question.

A number of needs have been cited to justify key escrow cryptography.Some apply to the needs of law enforcement and national security, whileothers apply to the needs of individual users or organizations:

Law enforcement and national security agencies are concerned thatgrowing use of encrypted communications will impair their ability to usecourt-ordered wiretapping to solve crimes and prevent acts of terrorism.Widespread use of key escrow cryptography would preserve this abilityfor these agencies, while providing the public with the benefits of goodquality cryptography. In the case of law enforcement and nationalsecurity, government escrow agents provide access to communications whenauthorized by a court order.

Some corporations have expressed a concern that careless or maliciousmismanagement of keys by employees might deny the corporation access toits valuable informnation. Key escrow cryptography at the corporatelevel has been advocated as a mechanism by which such corporations mightregain access to their information. In this sort of application, onemight have senior management or personnel offices serve as escrow agentswho would permit an employee's supervisor to gain access to his or herfiles or communications.

Individuals who use encryption for their own information may forget orlose the passwords that protect their encryption keys, die, or becomeincapacitated. Key escrow cryptography has been proposed as a safetymechanism for such individuals. In this case, an individual might selectfriends or attorneys as escrow agents who would allow the individual (orperhaps the executor of his or her estate) access to protectedinformation.

In some cases, government agencies have the authority to monitor thebusiness communications of their employees. Such authority applies, forexample, in military and national security installations where it isused to detect the misuse of classified or sensitive information. Keyescrow cryptography offers such agencies the opportunity to exercisetheir authority to monitor even for encrypted communications. In thisapplication, communications security officers might serve as escrowagents who would grant access to line managers or commanders.

The Clipper initiative focuses on the first of the four applications forkey escrow cited above. In addition, the Clipper initiative couples theintroduction of key escrow with the introduction of Skipjack, a newclassified encryption algorithm much stronger than the unclassified DES.

Opponents of the Clipper initiative have argued that a key escrowencryption system such as Clipper can be defeated by sophisticated userssuch as organized crime, who have the ability to write or buy their ownencryption system (without key escrow) and either ignore the key escrowproducts altogether or encrypt first under their own system and thenunder the key escrow system. Other options are open to pairs of userswho wish to cooperate to defeat key escrow, and some opponents of theClipper initiative have suggested that the only way to deter suchoptions is to forbid non-escrowed encryption by law and to enforce thelaw with a vigorous program of monitoring communications--an unappealingprospect to say the least.

Proponents of the Clipper initiative counter that they are well awarethat pairs of cooperating users have many ways to avoid key escrow. Theobjective that these proponents cite is to make it difficult orimpossible for a single "rogue" user to communicate securely withparties (or more precisely with escrowed encryption devices) thatbelieve they are engaged in a communication where both communicants arefaithfully following the escrow rules.

The "single rogue user" scenario constitutes. a test for a key escrowsystem. A successful key escrow system (hardware or software) shouldprevent a single rogue user from exploiting the cryptography in theescrowed product, and from defeating or bypassing the product's keyescrow features, while still enabling secure communication with otherusers products) that believe that they and the rogue user areimplementing the escrow features correctly.

The "Clipper" chip addresses the "single rogue user" by embedding thekey for each individual communication session in a Law EnforcementAccess Field (LEAF) that is encrypted under a secret key (the FamilyKey) that is common to all "Clipper" chips. the embedded informationincludes a checksum that depends on the session key. The receiving"Clipper" chip also holds the Family Key; thus, it can decrypt the LEAFand verify that the checksum is the correct one for the current sessionkey (which both chips must share in private for communication to besuccessful and secure). All "Clipper" chips share the embedded FamilyKey and rely on the temperproof hardware of the chip to protect theFamily key from disclosure.

Hardware Implementatwon of Key Escrow Cryptography

There are several factors that support the decision to require the useof separate hardware in the design of the key escrow products proposedas part of the Clipper initiative (Clipper and Capstone chips). Some ofthese factors, discussed below, are related to the introduction of keyescrow cryptography, some to the use of a classified encryptionalgorithm, and some to the choice of a conservative standard for thedesign of encryption products.

Separate hardware provides a degree of protection for the encryptionprocess difficult to obtain in software systems. An errant or maliciouscomputer program can not corrupt the encryption algorithm or keymanagement embedded in a hardware encryption device such as the Clipperor Capstone chip.

Separate hardware provides a degree of protection for the key escrowprocess difficult to obtain in software systems. While software canmanipulate the externally visible parameters of the escrow process,hardware at least provides some assurance that the escrow operations areperformed or verified.

If a classified encryption algorithm such as Skipjack is used, separatehardware that implements special protective measures may be essential toprotect the design of the algorithm from disclosure.

Secret cryptographic keys can be provided with a high degree ofprotection on a hardware device since unencrypted keys need never appearoutside the device. In contrast, it is difficult or even impossible toprotect secret keys embedded in software from users with physicalcontrol of the underlying computer hardware.

Proliferation of an encryption capability is perceived to be easier tocontrol with respect to accounting for controlled devices andrestriction of exports with hardware devices than with embeddedsoftware.

The list above makes it clear that some of the need for hardware in theClipper initiative derives from a need to protect the classifiedSkipjack algorithm, some from conservative design of the encryptionsystem, and some from a need to protect the escrow process.

Use of a Classified Data Enciyptdon Algorthm

The Skipjack encryption algorithm that was introduced with the Clipperinitiative is claimed to be much stronger than existing publiclyavailable algorithms such as DES. Having a strong algorithm is avaluable selling point for any new encryption initiative. But, as thediscussion above pointed out, protecting a classified algorithm fromdisclosure requires, at least at the current state of technology, ahardware implementation that embodies special measures to resist reverseengineering.

Classified encryption algorithms are often considered much stronger thanthose in the public domain since the algorithms used to protectgovernment classified information are classified. But because they arenot available for public review, suggestions that classified algorithmsbe used to protect unclassified information are suspect due to thepossible existence of unknown deliberate trapdoors or unintentionalflaws. While DES was initially viewed with suspicion by some, it wassubject to intense public scrutiny and its principal strength now isthat even after fifteen years, no serious flaw has been found.

Key escrow techniques as such do not require classified algorithms andcan be used with publicly available algorithms such as DES and IDEA orwith proprietary but unclassified algorithms such as RSADSI's RC2 andRC4. If a publicly available or proprietary unclassified algorithm wereused in a product that embodied key escrow cryptography, it would not benecessary to have a hardware implementation for the purpose ofprotecting the encryption algorithm from disclosure (although there areother reasons for implementing key escrow cryptography in hardware, asthe above list indicates).

This interdependence between hardware implementation and classifiedalgorithm has caused considerable confusion in examining the feasibilityof software key escrow approaches. If one requires a classifiedalgorithm, one must use hardware to protect the algorithm whether oneimplements key escrow or not. If one chooses an unclassified public orproprietary algorithm, one is free to implement in hardware or software.The decision to implement in hardware and software is driven by otherfactors, such as those identified in the above list.

Benefits and Limitations of Software Encryption

Historically, encryption systems that have been used to protectsensitive information have been implemented as separate hardwaredevices, usually outboard "boxes" between a computer or communicationssystem and a communications circuit. Such devices are designed with ahigh level of checking for operational integrity in the face of failuresor malicious attack, and with especially careful measures for theprotection of cryptographic functions and keys.

Software encryption systems have historically been viewed with suspicionbecause of their limited ability to protect their algorithms and keys.The paragraphs above discussed the issues associated with protectingclassified (or secret) encryption algorithms from disclosure. Over andabove these issues is the fact that an encryption algorithm implementedin software is subject to a variety of attacks. The computer's operatingsystem or a user can modify the code that implements the encryptionalgorithm to render it ineffective, steal secret cryptographic keys frommemory, or, worst of all, cause the product to leak its secretcryptographic keys each time it sends or receives an encrypted message.

The principal disadvantage of using encryption hardware, and thereforethe primary advantage of integrated software implementations, is cost.When encryption is implemented in hardware, whether a chip, a board orperipheral (such as a PCMCIA card) or a box, end users have to pay theprice. Vendors must purchase chips and design them into devices whosecosts go up because of the additional "real estate" required for thechip. End users must purchase more expensive devices with integratedencryption hardware, or must buy PCMCIA cards or similar devices andthen pay the price for adding a device interface to their computingsystems or dedicating an existing interface to encryption rather thananother function such as that performed by a modem or disk.

A second major advantage of software implementations is simplicity ofoperation. Software solutions can be readily integrated into a widevariety of applications. Generally, the mass market software industry,which attempts to sell products in quantities of hundreds of thousandsor millions, seeks to implement everything it can in software so as toreduce dependencies on hardware variations and configurations and toprovide users with a maximum of useful product for minimum cost.

SUMMARY OF THE INVENTION

The present invention is directed to a system and method for key escrowcryptography for use in a system comprising a sender and a receiver. By"sender" we mean a program or device that encrypts data for subsequenttransport or storage. By "receiver" we mean a program or device thatdecrypts data that has been received or retrieved from storage. Onlypublic keys are stored in the sender and the receiver so there is noneed for secrecy of the software. According to one embodiment of thepresent invention, the sender encrypts a message using a secret sessionkey (KS), and generates a leaf verification string (LVS) by combining anunique program identifier (UIP), a public portion of a program uniquekey (KUpub), and a signature. The signature represents the UIP and KUpubsigned by a private portion of a key escrow programming facility (KEPF)key (KEPFpriv). An encrypted LVS (ELVS) is formed by encrypting LVSusing KS.

The sender encrypts the KS using the KUpub to generate a first encryptedsession key (EKS), and generates a first law enforcement access field(LEAF) by encrypting a combination of the first EKS and the UIP with acopy of a public portion of a family key (KFpub) stored in the sender.The encrypted message, the ELVS, and the first LEAF are transmitted fromthe sender to the receiver.

The receiver operates as follows. The receiver stores therein a publicportion of the KEPF key (KEPFpub) and a public portion of the Family KeyKFpub). The receiver decrypts ELVS using KS and extracts the UIP, KUpub,and the signature from the LVS, and verifies the signature usingKEPFpub. If the verification succeeds, the receiver then encrypts the KSusing the extracted KUpub to generate a second encrypted session key(EKS). The receiver generates a second LEAF by encrypting a combinationof the second EKS and the extracted UIP with a copy of the KFpub storedin the receiver. The receiver then compares the first LEAF to the secondLEAF. If the first LEAF is equal to the second LEAF, then the receiverdecrypts the encrypted message using the KS.

This embodiment of the present invention operates so that, with neithertamper resistance nor secrecy of the hardware or software of the senderor the receiver, no party having modified the hardware or software ofeither the sender or receiver can communicate successfully with anunmodified receiver or sender and, at the same time, prevent lawenforcement from gaining authorized access to the communication.

According to another embodiment of the present invention, an encryptinguser encrypts a file using a secret storage key (KS) and generates adata recovery field (DRF) comprising an access rule index (ARI) and KSencrypted by a data recovery center (DRC) public key (DRCpub). DRCpub isacquired in an initial registration phase wherein the AR defining userdefines a set of access rules (ARs) that control potential lateraccesses to the DRF contents. After the DRC receives the AR from the ARdefining user, the DRC returns the ARI to be included in one or moreDRFs attached to subsequent encrypted files.

To decrypt the file encrypted with KS, a normal decrypting user useswhatever mechanism is customary for specifying or accessing a storagekey, KS. Failing that, emergency access is achieved via the DRF. In thiscase, the emergency decrypting user extracts the DRF attached to theencrypted message and sends the DRF to the DRC. The DRC challenges theemergency decrypting user according to the ARs defined by the ARdefining user and sends a message containing KS to the emergencydecrypting user if the emergency decrypting user meets the challenge.

In alternative embodiments, KS is not an encryption key but rather anypiece of confidential information that can fit inside the DRF. In allcases, the DRC limits access to emergency decrypting users who can meetthe challenge defined by the AR indicated by the ARI in the DRF.

Further features and advantages of the present invention, as well as thestructure and operation of various embodiments of the present invention,are described in detail below with reference to the accompanyingdrawings. In the drawings, like reference numbers indicate identical orfunctionally similar elements.

BRIEF DESCRIPTION OF THE FIGURES

The present invention will be described with reference to theaccompanying drawings, wherein:

FIG. 1 is a block diagram of a key escrow cryptographic system accordingto a first embodiment of the present invention;

FIGS. 2-9 and 17 are flowcharts depicting the key escrow cryptographicsystem according to the first embodiment of the present invention;

FIG. 10 is a block diagram of a key escrow cryptographic systemaccording to a second embodiment of the present invention;

FIGS. 11-16 are flowcharts depicting the key escrow cryptographic systemaccording to the second embodiment of the present invention;

FIG. 18 is a block diagram of a data processor according to anembodiment of the present invention.

FIG. 19 is a block diagram of a data escrow cryptographic systemaccording to a third embodiment of the present invention;

FIGS. 20, 24 and 26 are data flow diagrams depicting the process ofaccess rule definitions;

FIGS. 21-23 and 25 are flow charts depicting access rule definitions;

FIG. 27 is a preferred embodiment of the construction of a data recoveryfield;

FIG. 28 is a flow chart depicting the processing of emergency accessrequests;

FIG. 29 is a flow chart of an exemplary challenge-response cycle;

FIG. 30 is a data flow diagram depicting a challenge-response cycleembedded within an emergency access request; and

FIG. 31 is a data flow diagram depicting a retrieval of an access rulefrom a data recovery field.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention is directed to a system and method for key Descrowcryptography. Preferably, the present invention is implemented insoftware. However, the present invention works equally well whenimplemented using hardware.

The present invention preferably employs an unclassified data encryptionalgorithm. Thus, the objection that software cannot protect a classifiedencryption algorithm does not apply to the present invention.

Another objection against software is that it cannot ensure that the keyescrow software will function correctly and not be modified by a user tobypass or corrupt the escrow process. It is noted that this objection isnot limited to just software, but also applies to hardwareimplementations which allow software to control the flow of informationto and from the hardware encryption device.

Another objection against software is that it is impossible to embedsecret cryptographic keys in a software product without a significantrisk that they would be disclosed. The present invention addresses andsolves this problem inherent in conventional software implementations ofkey escrow by not embedding secret keys or private keys in the senderand receiver software modules. This feature of the present invention isdiscussed below.

Preferably, in the present invention, encryption and decryptionoperations are performed using any well known, unclassified, andpublicly available algorithms such as DES and IDEA or with any wellknown, proprietary but unclassified algorithms such as RSADSI's RC2 andRC4. The specific details of the encryption and decryption algorithm arenot material to the present invention.

The following symbols are used herein.

[a]b indicates that "a" is encrypted using key "b"; similarly,encrypt(e,f) indicates that "e" is encrypted using key "f".

{x}y indicates that "x" is digitally signed using well known proceduresusing key "y"; similarly, sign(a,b) indicates that "a" is digitallysigned using key "b".

a|b indicates that "a" is concatenated with "b".

decrypt(m,n) indicates that "m" is decrypted using key "n".

extract(g,h) indicates that "h" is extracted using well known proceduresfrom concatenated value "g".

verify(a,b,c,) indicates that the signature "b" or "a" is verified usingkey "c".

xor(o,p) indicates that "o" is bitwise exclusive-OR'ed with "p".

As used herein, values having labels with a suffix "priv" are consideredto be private or secret. Values having labels with a suffix "pub" areconsidered to be public.

Concerning the symbol represented by Z=[X]Y (X encrypted by Y), if Y isa public key, and Z needs to be re-built by some other program nothaving the private key corresponding to Y, then this encryption needs tobe direct with all unused bits around X either known or communicated tothe re-building process. If there is no need to re-build Z, this can beeither direct or indirect encryption. That is, one can equivalentlycompute Z=([X ]K₁,[K₁ ]Y) (where K₁ is a conventional, randomly chosen,symmetric encryption key) and achieve the same functional result. Thismay be desirable if X is larger than the quantity one can encryptdirectly under Y in one pass. Similarly, one might also computeZ=([X]K₂,[K₂ ]K₁,[K₁ ]Y).

Overview of the Present Invention

Described below are three embodiments, two applying to a system andmethod of key escrow cryptography and a third applying to data escrowcryptography. The first two embodiments generally share the followingpreferred features:

Both embodiments ensure that no party having modified the software ofsender or receiver can communicate successfully with an unmodifiedreceiver or sender and, at the same time, deny law enforcementauthorized access to the communication.

For both embodiments, the receiving party to a communicationreconstructs the sender's LEAF to verify that the received LEAF is bothvalid and the correct LEAF for the current encrypted communication. Thischoice counters single rogue attacks.

Both use an escrow protocol based on public key cryptography to buildthe law enforcement access field (LEAF) that makes the user's keysavailable to law enforcement authorities. This choice obviates the needto include in the software products any secret keys that would be partof the escrow process.

Both preferably use unclassified public or proprietary encryptionalgorithms to perform all cryptography functions.

The third embodiment, on the other hand, focuses on the recovery ofstored information rather than the recovery of transmitted information.In this embodiment, the data recovery field (DRF), an analogousstructure to the LEAF, allows a user to function in a similar role tothe law enforcement authorities of the previous embodiments. Access canbe obtained not only through a court imposed order but also through anyset of access rules (ARs) defined by the sender.

1. First Embodiment

FIG. 1 is a block diagram of a key escrow system 102 according to afirst embodiment of the present invention. The key escrow system 102includes a key escrow programming facility (KEPF) 106, two or more keyescrow agents (KEAs) 110, 114, sending and receiving entities 124, 130,and a law enforcement decryptor 120.

A block diagram of the sending entity 124 is shown in FIG. 18.Preferably, the sending entity 124 is a data processing device 1802having a central processing unit (CPU) 1804 connected to other devicesvia a data bus 1810. The CPU 1804 operates in accordance with controllogic 1806. Control logic 1806 is preferably a computer program, suchthat the CPU 1804 operates in accordance with instructions contained inthe computer program.

The data processing device 1802 also includes a communications orstorage device 1808, a monitor 1812, a keyboard 1814, and a printer1816. Communications between the sending entity 124 and other devices,such as the receiving entity 130, are achieved by operation of thecommunication or storage device 1808, which is any well knowntransmitter or storage medium.

In accordance with the present invention, the control logic 1806 enablesthe sending entity 124 (and, in particular, the CPU 1804) to operate asdiscussed herein. For example, the control logic 1806 (when executed bythe CPU 1804) enables the sending entity 124 to perform the steps shownin FIG. 7.

The structure of the receiving entity 130 is similar to the sendingentity 124 and, thus, the above description applies equally well to thereceiving entity 130. However, in accordance with the present invention,the control logic 1806 in the receiving entity 130 enables the receivingentity 130 (and, in particular, the CPU 1804) to operate as discussedherein. For example, the control logic 1806 (when executed by the CPU1804) enables the receiving entity 130 to perform the steps shown inFIG. 8.

Since the control logic 1806 in both the sending and receiving entities124, 130 preferably represent software, the sending and receivingentities 124, 130 are sometimes called herein "programs". However, itshould be understood that such "programs" represent a device 1802operating in accordance with software. Also, according to an alternateembodiment of the invention, the sending and receiving entities 124, 130are implemented entirely in hardware (for example, the CPU 1804 and thecontrol logic 1806 represent hardware state machine(s)).

As mentioned above, one difference between this system 104 and theClipper/Capstone system is that this system 104 uses public keycryptography in place of conventional (symmetric) cryptography togenerate the law enforcement access field or LEAF. As is well known,with symmetric cryptography, sender and receiver share a key that isused to control both encryption and decryption. With asymmetriccryptography, encryption and decryption use separate keys which cannotbe computed from one another. Thus, an encryption key can be made public(a "public key") and anyone can send a secret message which can only bedecrypted by the holder of the corresponding ("private") decryption key.The use of public key cryptography allows the software programs 124, 130to generate and validate LEAFs without having to store secret keys orprivate keys. Only public quantities need be embedded in the softwareprograms 124, 130 and, therefore the present invention does not need topreserve the secrecy of its own structure or content. The elements ofthe system 102 shall now be described.

1.1 The Key Escrow Programming Facility

The key escrow programming facility (KEPF) 106 is within a protectedenvironment 104. A protected environment 104 is defined as a physicallyand procedurally secured area whose protection is adequate to the valueof all information that will be protected by any key escrow encryptionprogram.

The KEPF 106 includes various cryptographic-related data 108. Such data108 stored in the KEPF 106 cannot be accessed by persons or entitiesoutside the protected environment 104. The manner in which the KEPF 106initializes such data 108 shall now be described with reference to aflowchart 202 in FIG. 2.

The KEPF 106 is initialized with two public/private key pairs. The firstis a KEPF public/private key pair, initialized in steps 206, 208, 210,and 212, which is used to sign and authenticate other components thatare generated and distributed by the KEPF 106. The KEPF key pair isgenerated externally and loaded into the KEPF 106 (step 208), orgenerated internal to the KEPF 106 (step 210). Controls can be appliedto the generation and custody of the KEPF key pair as they are to thefamily and seed keys that are used by the Clipper/Capstone chipprogramming facility. The KEPF public/private key pair is stored in amemory device in step 212.

The second key pair used by the KEPF is a family key (KF) and isinitialized during steps 214, 216, 218, 220, and 222. KF is preferablygenerated external to the KEPF 106 (step 216), although it may begenerated internally (step 218). Only the public component (KFpub) issent to the KEPF 106 (step 222). The corresponding private component(KFpriv) is loaded into the Law Enforcement Decryptor (LED) 120 (step220). The private component of KF can also be split into halves andescrowed.

1.2 Law Enforcement Deczyptor

The Law Enforcement Decryptor (LED) 120 is also within the protectedenvironment 104. the LED includes the Family Private Key KFpriv 122.

The LED 120 initializes the Family Private Key 122 as shown in FIG. 4.In step 406, the LED obtains the private component of KF, KFpriv, whichis stored in a memory device in step 408.

1.3 Generating Program Parameters

On an ongoing basis, the KEPF 106 signs and optionally generates uniqueprogram parameters for each program instance, just as theClipper/Capstone programming facility programs each individual chip. Inparticular, as shown in a flowchart 302 of FIG. 3, the KEPF 106 in step306 sends the KEPFpub and KFpub to a software vendor/user 118. Steps308-324 are then performed for each program instance.

In step 308, the KEPF 106 generates or acquires a program uniqueidentifier (UIP) and a program unique key (KU). Preferably, KU is anasymmetric public/private key pair. KU is generated within the KEPF 106and may be seeded with externally generated parameters that are loadedinto the KEPF 106. The private component of KU (KUpriv) is split intohalves (308). This is preferably done by generating a random bit stringas long as KUpriv which becomes KUpriv1 and calculating KUpriv2 as theexclusive-OR of KUpriv1 and KUpriv. Other procedures could alternativelybe used to split KUpriv.

In step 310, the UIP and individual private key halves are escrowed withthe two escrow agents (KEAs) 110, 114. Specifically, as shown in aflowchart 501 in FIG. 5, the escrow agent 110 receives the UIP andKUpriv1 (step 504) and stores UIP and KUpriv1 (step 506). These stepsare repeated for each program instance, as indicated by step 508. Theoperation of the other escrow agent 114 is identical to this.

In steps 312 and 314, the KEPF 106 sends the program unique parameters,UIP and KUpub, to the software vendor 118 to be embedded into thesoftware program product. In step 312, the KEPF 106 uses well knownprocedures to digitally sign these parameters using its private key,KEPFpriv, and sends the signature along with the components to thesoftware vendor 118 (step 314). The programming facility public key(KEPFpub) and the family key public component (KFpub) are also sent tothe vendor 118. Steps 308-314 are repeated for each program instance, asindicated by step 316.

1.4 Generating the Software Product

If the KEPF 106 communicates its public key KEPFpub to the vendor 118 byan out of band (secure) channel, the vendor 118 can reliablyauthenticate sets of parameters (KFpub, UIP, KUpub) received from theKEPF 106. This is the case since, as is well known, data encrypted (ordigitally signed) with a private key can be decrypted (or verified) byanyone possessing the corresponding public key. Also, data encryptedwith a public key can be decrypted only using the corresponding privatekey.

As represented in a flowchart 602 of FIG. 6, as the software vendor 118manufactures software copies of its product, it embeds KFpub and KEPFpubin the product code (step 608). It had received KFpub and KEPFpub fromthe KEPF 106 (step 606). Each instance of the program must beinitialized with:

KEPFpub

KFpub

KUpub unique to that instance of the program

UIP unique to that instance of the program

S={KFpub, KUpub, UIP}KEPFpriv unique to that instance of the program.

This data can reside in the code of the program or in a storage fileassociated with the program. KEPFpub, KFpub, and S must come from theKEPF. KUpub, KUpriv, and UIP can be generated by the KEPF, the vendor orthe program itself during initialization. S must be generated by theKEPF only on receipt or generation of a valid KUpub, KUpriv, pair andthe successful escrowing of KUpriv.

Preferably, the vendor 118 embeds the program unique parameters (UIP,KUpub and the associated signatures) for each program into the media forthe program (step 612). UIP, KUpub and the associated signatures werereceived from the KEPF 106 in step 610. Steps 610 and 612 are performedfor each software product, as indicated by step 614.

The data described above is represented by reference number 126 in thesending program 124 and reference number 132 in the receiving program(FIG. 1).

Note that no secret keys or private keys are present-within the softwareproduct. Only public quantities, KEPFpub, KFpub, and KUpub are embeddedin the software product.

In cases where a software product is distributed on CDROM media that ismanufactured in bulk (and can not accept unique serial number or keyinformation), or where it is installed on a shared storage device foraccess by multiple users, it is not feasible to embed a unique KUpub,UIP and the associated signatures. for each copy of the product. Inthese cases, the user of the product can be required to run aninstallation program that retrieves KUpub, and UIP and their signatureover a network or communication line. The operation of the product'sencryption function can be made contingent on the execution of theinstallation program and possession of KUpub, UIP, and the correspondingvalid signature.

Since the only quantities that are needed to customize the escrowsoftware for its user are signed digitally and public, there is no riskto retrieving them over a network or other insecure communicationchannel. Their confidentiality is not at issue, and their integrity canbe authenticated using KEPFpub which is common to all users and copiesof the product and can be embedded by the vendor 118.

An alternative to having the product retrieve KUpub and UIP is to havethe product generate UIP and KU during the initialization process andsend all components (UIP, KUpub and KUpriv) to the KEPF 106 encryptedunder KEPFpub. In this variation, the KEPF 106 would split KUpriv anddistribute the halves to the escrow agents 110, 114, sign [UIP/KUpub],KUpub and send {UIP|KUpub}KEPFpriv back to the product.

1.5 Operation of the Sending Program

As represented by a flowchart 702 in FIG. 7, the sending program 124receives a data message M in step 706. In step 708, the sending program124 and the receiving program 130 use any well known procedure fornegotiating a secret session key 708. In steps 710 and 712, the sendingprogram 124 encrypts and then transmits the data message M using thesecret (or private) session key KS. This encrypted message C is denotedby [M]KS.

Also in step 710, the sending program 124 generates a LEAF by encryptingthe session key KS under the program unique public key KUpub to therebygenerate [KS]KUpub. [KS]KUpub is also called the encrypted session key,or EKS. The EKS is concatenated with the program unique identifier UIPto thereby generate [KS]KUpub | UIP. This value is encrypted with thefamily public key KFpub. The resulting LEAF is symbolized as[[KS]KUpub|UIP]KFpub. Note that in the present invention encryption of Mis accomplished using symmetric encryption while encryption in the LEAFunder keys KUpub and KFpub is accomplished using asymmetric, rather thansymmetric cryptography.

Also in step 710, the sending program 124 generates a LEAF verificationstring (LVS) that includes: (1) the sending program 124's program uniqueidentifier UIP, (2) program unique public key KUpub, and (3) thesignature S applied to those two quantities by the key escrowprogramming facility 106, i.e., {UIP,KUpub}KEPFpriv (these three itemsare called the leaf verification string, LVS). This string is encryptedunder the session key, KS. Thus, the ELVS, is represented as follows:

[UIP, KUpub, {UIP,KUpub}KEPFpriv]KS

In step 712, C, LEAF, and ELVS are sent to the receiving program 130.

1.6 Operation of the Receiving Program

As represented in a flowchart 802 of FIG. 8, the receiving program 130in step 806 negotiates a secret session key KS with the sending program124 (this corresponds to step 708 in FIG. 7). In step 808, the receivingprogram 130 receives C, LEAF, and ELVS from the sending program 124.

In step 820, the receiving program 820 decrypts the encrypted message Cusing the session key KS to recover the message M. However, prior todoing so, the receiving program 820 must authenticate the LEAF to ensurethat the sending program 124 has included a valid LEAF as part of themessage transmission. This is done during steps 810, 812, 814, and 816.

Note that the receiving program 130 cannot decrypt the LEAF, since itdoes not have a copy of the family private key KFpriv. Instead,according to the present invention, the receiving program 130authenticates the LEAF by reconstructing it. This is possible since thereceiving program 130 has been provided with all of the components thatmake up the LEAF either through communication external to the operationof the escrow system (KF and KS) or because they were sent signed in theencrypted LEAF verification string ELVS.

Specifically, in step 810 the receiving program 130 decrypts theencrypted leaf verification string ELVS using the session key KS toobtain the leaf verification string LVS, or {UIP, KUpub,UIP|KUpub}KEPFpriv. Then in step 810 the receiving program 130 verifiesthat the received copies of the sending program 124's program unique keyKUpub and program unique identifier UIP (which are in the LVS) arecorrect and authentic. This is done in step 812 by verifying thecorresponding signature S or {UIP|KUpub}KEPFpriv using KEPFpub

If the leaf verification string LVS is authentic (as determined in step812), then the receiving program 130 in step 814 recalculates the LEAF(this is called the "test₋₋ LEAF" in FIG. 8) using KS, KFpub, and thesending program 124's. KUpub and UIP. If the calculated LEAF isidentical to the one received (as determined in step 816), then the LEAFis valid. Accordingly, the receiving program 130 accepts and decryptsthe message (step 820). Otherwise, the receiving program 130 rejects themessage (step 818).

The use of the session key KS to encrypt the leaf verification stringLVS is not necessary to the function of verifying the LEAF. Instead,this step protects the sending program 124's UIP and KUpub fromdisclosure to parties who are not in communication with it.

1.7 Law Enforcement Decryptor

The law enforcement decryptor (LED) 120, which is operated by the lawenforcement agency, contains the family private key KFpriv (indicated as122 in FIG. 1). This is represented in a flowchart 402 of FIG. 4, wherethe LED 120 receives the KFpriv from the KEPF 106 in step 406(corresponding to step 220 in FIG. 2 in the case where KFpriv isgenerated in the KEPF 106; where KFpriv is generated outside the KEPF106 by an external entity, not shown, then the external entity sends theKFpriv to the LED 120). In step 408, the LED 120 stores the KFpriv in amemory device of the LED 120.

Since the LED 120 has possession of KFpriv, the LED 130 can decrypt theLEAF. This operation is represented in a flowchart 1702 in FIG. 17. Instep 1706, the LED 120 receives C, LEAF, and ELVS from the sendingprogram 124. In step 1708, the LED 130 decrypts the LEAF using KFpriv,and extracts the UIP from the decrypted LEAF (called "plain₋₋ LEAF" inFIG. 17). In steps 1710, 1712, 1714 and 1716, the LED 120 uses UIP toobtain the sending program 124's unique private key components, KUpriv1and KUpriv2, from the respective key escrow agents 110, 114. If eitherkey escrow agent indicates that they cannot find the private keycomponent corresponding to UIP, then the LEAF is invalid (step 1724). Instep 1718, the LED 130 combines KUpriv1 and KUpriv2 using preferably awell known exclusive-OR operation to form the sending program 124'sprogram unique key, KUpriv. KUpriv is stored in the LED 120 in step1720. With KUpriv, the LED 130 in step 1722 decrypts the session key KS.Also in step 1722, given KS, the LED 120 decrypts the message.

2. Second Embodiment: On-line Escrow Agents

The key escrow protocol of the Clipper initiative has been criticizedsince it was initially disclosed because of the fact that a device whoseunique key (KU in the original Clipper scheme) has been withdrawn fromthe escrow agents is subject to decryption from the time of withdrawalonward. While the stated policy of the Clipper initiative is that uniquekeys will be erased from the law enforcement decryptor (LED) once thewiretap authorization has expired, that policy is cold comfort toindividuals who find key escrow unappealing to begin with.

The first embodiment of the software key escrow system of the presentinvention, described above, shares with the Clipper initiative the useof a device unique key (KUpriv) that is loaded into the law enforcementdecryptor LED 120 and that must be erased when a wiretap authorizationhas expired. In addition, it is possible that a malicious user with amodified software product can harvest and reuse the escrow information(UIP and KUpub) for any other user with whom he or she communicatessecurely potential deficiency, in that it can cause the law enforcementagency to retrieve KUpriv for innocent partner.

The second embodiment of the software key escrow system of the presentinvention addresses and solves these concerns. The second embodimentdoes away with the unique key (KU, KUpub, KUpriv) and identifier (UIP).Instead, each sender splits its session key KS and encrypts one fragmentunder the public key of each escrow agent. This scheme stillincorporates a LEAF and a LEAF verification string, but it does awaywith the KEPF and simplifies the role of the vendor.

FIG. 10 is a block diagram of the second embodiment. KEApub1 andKEApriv1 (designated as 1008) are stored in the key escrow agent 1006,and KEApub2 and KEApriv2 (designated as 1012) are stored in the keyescrow agent 1010. Note that there is no key escrow programming facility(KEPF). However, there is some entity (not shown; this entity could becalled the KEPF) in the protected environment 1004 that initializes thekey escrow agents 1006 and 1010. Such initialization is represented by aflowchart 1102 in FIG. 11, where in step 1108 the entity obtains KEApub1and KEApub2 from an external source (not shown). Alternatively, in steps1110 the entity generates KEApub1, KEApriv1, KEApub2, and KEApriv2,sends KEApriv1 and KEApub1 to key escrow agent 1006, sends KEApriv2 andKEApub2 to key escrow agent 1010, and erases KEApriv1 and KEApriv2. Instep 1114, the entity stores KEApub1 and KEApub2. In step 1116, theentity sends KEApub1 and KEApub2 to the software vendor 1014.Alternatively, as shown in FIG. 10, KEApub1 and KEApub2 are sent to thesoftware vendor 1014 from key escrow agents 1006 and 1010.

The vendor 1014's sole role is to embed in each program instance thecode that implements the key escrow functions and the public keys of two(or more) escrow agents (KEApub1 and KEApub2). These keys arerepresented by 1020 and 1026 in the sending program 1018 and thereceiving program 1024, respectively. The operation of the softwarevendor 1014 is represented in FIG. 12, where in step 1206 the softwarevendor 1014 receives KEApub1 and KEApub2 from the key escrow agents1006, 1010, in step 1208 the software vendor 1014 stores KEApub1 andKEApub2, and in steps 1210 and 1212 the software vendor 1014 embedsKEApub1 and KEApub2 in each software program.

The sending program 1018 operates as shown in a flowchart 1302 of FIG.13. In step 1306, the sending program 1018 receives a message M. In step1308, the sending program 1018 negotiates a secret session key KS withthe receiving program 1024 using any well known procedure. In step 1310,the sending program 1018 encrypts the message M using the session keyKS.

In step 1312, the sending program 1018 splits the session key KS intotwo halves KS1 and KS2. Preferably, this is known by assigning a randomnumber to KS1, and then assigning KS2 to the exclusive-OR of thisrandom. number and KS. The sending program 1018 also generates a LEAFduring step 1312. The LEAF is equal to the concatenation of (1) KS1encrypted under KEApub1 and (2) KS2 encrypted under KEApub2, and can berepresented by:

LEAF=([KS₁ ]KEApub₁, [KS₂ ]KEApub₂)

The LEAF need not be encrypted with KFpub, since KEApriv_(i) are notavailable to anyone and presumably the only path to these decryptingservices is via the LED. The KEApub_(i) encryptions are enough topreserve the privacy of the LEAF contents without resorting to KFpubencryption. However, if there is some communications path to the"escrow" (decrypting) agents other than through the LED or if there areto be different classes of user, some of which the LED may not beallowed to access, the family key, KFpub, provides needed security. Itshould be noted that this embodiment is not limited to a 2-way splitsession key. In alternative embodiments, any number of splits, from 1 onup may be utilized. The general LEAF is represented by:

LEAF=([KS₁ ]KEApub₁, [KS₂ ]KEApub₂, . . . , [KS_(n) ]KEApub_(n)) or

LEAF=[[KS₁ ]KEApub₁, [KS₂ ]KEApub₂, . . . , [KS₋₋ n]KEApub_(n) ]KFpubfor n>0

The choice of LEAF construction depends on whether or not extraprotection from KFpub encryption is desired. At some point, however,encryption of all pieces under one KFpub key may become prohibitive whenconsidering the size of that one key.

Further in step 1312, the sending program 1018 generates a leafverification string LVS that is equal the concatenation of KS1 and KS2.The encrypted leaf verification string ELVS is then generated and isequal to the LVS encrypted using the session key KS.

In step 1314, C, LEAF, and ELVS are sent to the receiving program 1026.

The operation of the receiving program 1024 is shown in a flowchart 1402of FIG. 14. In step 1406, the receiving program 1024 receives C, LEAF,and ELVS from the sending program 1018. In step 1408, the session key KSis negotiated (this step corresponds to step 1308 in FIG. 13).

Then, the receiving program 1024 checks the leaf verification string LVSand then recomputes the LEAF. Specifically, in step 1410 the receivingprogram 1024 decrypts the encrypted leaf verification string ELVS usingKS to obtain the leaf verification string LVS. The putative KS1 and KS2called trial₋₋ KS1 and trial₋₋ KS2 are extracted from LVS. Then, thereceiving program 1024 generates the session key KS (called "trial-KS"in step 1412) by exclusive-OR'ing trial₋₋ KS1 and trial₋₋ KS2 that werejust extracted from LVS. In step 1412, the receiving program 1024compares trial₋₋ KS with the negotiated session key KS. If they are notequal, then the LEAF is bad and the message is rejected (step 1418).

If they are equal, then in step 1414 the receiving program 1024 uses itscopies of KEApub1 and KEApub2 to recompute the LEAF. This is done byencrypting trial₁₃ KS1 using KEApub1 and encrypting trial₋₋ KS2 usingKEApub2 to thereby generate trial₋₋ EKS1 and trial₋₋ EKS2, respectively.Then, a LEAF called test₋₋ LEAF is computed by concatenating trial₋₋EKS1 and trial₋₋ EKS2.

In step 1416, the receiving program 1024 determines if trial₋₋ LEAF isequal to the LEAF. If they are not equal, then the message is rejected(step 1418). If they are equal, then the LEAF is validated and themessage M is decrypted using KS.

The operation of the law enforcement decryptor LED 1016 is shown in aflowchart 1502 of FIG. 15. In step 1506, the LED 1016 receives the C,LEAF, and ELVS from the sending program 1018. In step 1508, EKS1 andEKS2 are extracted from the LEAF. In step 1510, the LED 1016 sends EKS1to key escrow agent (KEA) 1006 and sends EKS2 to KEA 1010. Also, the LED1016 discloses a proper court order to each escrow agent 1006, 1010.Each agent 1006, 1010 verifies the validity of the court order, recordsits effective dates, and generates a secret key half KS1 or KS2 usingeither KEA1priv or KEA2priv for that particular court order and issuesit to the LED 1016. This is represented by step 1512, where the LED 1016receives KS1 from KEA1 1006 and KS2 from KEA2 1010. The LED 1016combines the returned KS1 and KS2 to yield KS (step 1514), and decryptsthe message using KS (step 1516).

Any submission of key parts for that wiretap to an escrow agent 1006,1010 by the LED 1016 must be encrypted in the corresponding key. Theescrow agents 1006, 1010 delete the secret keys KS1, KS2 on theexpiration of the court order and are therefore unable to comply withany requests for keys after the expiration of the order. Since allcommunications with the escrow agents 1006, 1010 must be encrypted forsecurity, this process adds no execution time to that operation.

The operation of KEA11006 is shown in a flowchart 1602 in FIG. 16. KEA11006 and KEA2 1010 are identical, so the following description appliesequally well to KEA2 1010. In step 1606, the KEA1 1006 receives EKS1from the LED 1016. In step 1608, the KEA1 1006 decrypts EKS1 usingKEA1priv to obtain KS1. IN step 1610, the KEAL 1006 sends KS1 to the LED1016.

Since there is no database linking a UIP to any individual targeted in acourt order, the escrow agents 1006, 1010 have no choice but to trustthe LED 1016's association of an individual targeted by a court orderwith a specific wiretap. The protocol described above may be modified toinclude a UIP in the LEAF portions sent to the escrow agents 1006, 1010,to enable those agents 1006, 1010 to maintain a list of programinstances targeted under each court order for later auditing.

This second embodiment has the advantage that there is no product uniquekey to be disclosed to the LED 1016. Once surveillance ceases, the LED1016 has no further ability to decrypt the sending program 1018'scommunications unless it again requests the services of the escrowagents 1006, 1010. As a side effect, there is no potential for a rogueapplication to trick the LED 1016 into withdrawing the unique keys ofinnocent users.

This second embodiment requires the escrow agents 1006, 1010 to be online and involved with every decryption of a new session key. This isnot considered to be a disadvantage since the escrow agents 1006, 1010are committed to round-the-clock operation as part of the Clipperinitiative. On-line computer systems at the escrow agents can beexpected to respond within 0.2 seconds, provided they have hardwaresupport for public key decryption, and reliable communications betweenescrow agents and LED should be easy enough to provide.

3. Third Embodiment--Data Recovery Center

A third application of this technology applies to Data Recovery Centers(DRCs). This third embodiment is directed to the provision of emergencyaccess to stored encrypted data in the event of the loss of the normaldecryption key. It involves no key escrow or escrow agents and has nocommunications with third parties (specifically any DRCs) except duringan initial, registration phase and during the process of emergencyaccess.

This embodiment is similar to the second embodiment where no databasesof escrowed keys and therefore no escrowed keys and escrow agents exist.This embodiment, like the second embodiment, is directed towardsdecryption services. In the second embodiment, directed to lawenforcement interests, the entities performing the decryption serviceswere called Escrow Agents, even though they performed no escrowfunctions. In this embodiment, to appeal to corporate and individualinterests, the entities performing the decryption services are named theDRCs.

FIG. 19 illustrates a block diagram of an environment 1902 according tothis third embodiment. The environment 1902 includes a data recoverycenter (DRC) 1910 (optionally redundant) situated in a protectedenvironment 1904. The protected environment 1904 is established andmaintained by any entity wishing to provide services pursuant to thethird embodiment of the present invention (as described herein). Forexample, the protected environment 1904 may be established andmaintained by a public organization (such as a state division of motorvehicles) or a private organization (such as a corporation), or aplurality and/or combination of public/private entities. Preferably, theDRC 1910 represents software executing on a suitably equipped computersystem.

Functional elements 1912 (normal file decryption), 1914 (fileencryption), 1916 (emergency file decryption) and 1918 (AR definition)represent a user in the four different operational modes. In thefollowing description, the four elements will be referred to as thenormal decrypting user, the encrypting user, the emergency decryptinguser, and the AR defining user respectively. It should be understoodthat these users do not necessarily represent the same party.

In this embodiment, the AR defining user 1918 first negotiates with theDRC to obtain a DRC public key (DRCpub). The AR defining user 1918 thencreates an access rule (AR) definition and registers that AR definitionwith DRC 1910. The DRC 1910 sends an access rule index (ARI)corresponding to that AR back to the AR defining user 1918. The ARdefining user 1918 then stores any new DRCpub, the new ARI and anattached comment in the AR file 1920.

The encrypting user 1914 encrypts a File F with a storage key (KS) togenerate an encrypted file C=[F]KS. The encrypting user 1914 is anyentity wishing to encrypt data and store such encrypted data. Forexample, the encrypting user 1914 may be a commercial software program(such as a word processor program, a spreadsheet program, a databaseprogram, a communication program, etc.) running on a computer.

The encrypting user 1914 creates a data recovery field (DRF) comprisingan access rule index (ARI) and the KS encrypted by DRCpub. The ARI andDRCpub values are retrieved from the ARI file 1920. The ARI value isgenerated by the DRC 1910 during the initial set-up phase between the ARdefining user 1918 and the DRC 1910. The DRF is attached to theencrypted message C and is sent by the encrypting user 1914 to a storagemedium 1922. If it is desired to allow for reconstruction of the DRFduring a later verification phase, the encrypting user 1914 alsogenerates a DRF Verification String (DVS) and attaches it to the DRF.The (optional) DVS consists of the ARI which was used in the DRF,encrypted in the storage key, KS.

In this third embodiment, the encrypted message and the DRF are storedin a storage medium 1922 pending retrieval by either the normaldecrypting user 1912 or the emergency decrypting user 1916. Typically,the normal decrypting user 1912 is the same person as the encryptinguser 1914 who has access to the storage key, KS, without requiring anyreference to the DRC.

An emergency access situation occurs when an emergency decrypting user1916 does not have the KS required to decrypt the message. For example,this may happen in a corporate environment when a manager needs accessto data encrypted by an employee, but the employee is not present andthe manager does not know the employee's storage key, KS. It may alsohappen when the. encrypting user 1914 forgets KS or the normal means forgenerating it or gaining access to it. To access the KS, the emergencydecrypting user 1916 extracts the DRF from the storage medium 1922 andsends it to the DRC 1910. The DRC 1910 responds with a challengepreviously defined by the AR defining user 1918 at the registrationphase and selected by the encrypting user 1914 during encryption andreleases the KS contained within the associated DRF to the emergencydecrypting user 1916 if the emergency decrypting user 1916 successfullymeets the challenge. In this scenario, the emergency decrypting user1916 can generally be described as a party privileged to the informationoriginated by the encrypting user 1914 (e.g., management).

From a broader perspective, the KS within the DRF could represent anyconfidential piece of information to which the encrypting user 1914desires to control access. In other words, the intended use of the KSafter retrieval by an emergency decrypting user 1916 does not limit thescope of use of this embodiment.

Preferably, the data recovery center 1910, the client 1918, and the user1916 each represent a data processing device operating according toinstructions or commands from a controller. (In some embodiments, thedata processing device includes a processor, in which case the processoroperates according to instructions or commands from the controller.) Inone embodiment, the controller represents a hardware state machine. Inan alternate embodiment, the controller represents a computer program inan electronic/magnetic form that is directly readable by a computer.Preferably, the computer program is distributed as a computer programproduct (such as a floppy disk having control logic electronically ormagnetically recorded thereon), or via a communications network.

3.1 Data Recovery Field

Where the first two embodiments refer to a Law Enforcement Access Field(LEAF), the third embodiment refers to a Data Recovery Field (DRF).Since emergency access is provided only to emergency decrypting users1916 in this embodiment (e.g., an encrypting user 1914 himself or hisemployer), the preferred mode of this embodiment avoids the splitting ofKS. Clearly, in alternative modes, key splitting remains a possibleimplementation should an encrypting user 1914 desire it.

It should be noted that in alternative embodiments KS need not be astorage key (i.e., encrypting key). The datum inside a DRF can be anydatum which the encrypting user 1914 wishes to encrypt and store. Theenclosure of such a datum inside a DRF is functionally equivalent to theencryption of that datum in a file with a storage key (KS) generated atrandom. The randomly generated storage key (KS) is included within theDRF attached to the file and forces the file's owner to access thefile's contents as an emergency decrypting user 1916.

Further comparison to the second embodiment is evident throughconsideration of a LEAF with n=1 and no KFpub encryption. For thisexample, the LEAF is comprised of [KS₁ ]EApub₁ where [Y]X means Y,encrypted with key X. In comparison, the DRF of the third embodiment iscomprised of [ARI|KS]DRCpub. Here, the index to an access rule (AR)defined by an encrypting user 1914 is concatenated with the storage key(KS) chosen by the encrypting user 1914 and then encrypted in the publickey of the DRC, DRCpub. If the encrypting user 1914 views the DRC 1910as potentially hostile, an alternate embodiment implements a DRFcomprising:

[ARI₁,KS₁ ]DRCpub₁,[ARI₂,KS₂ ]DRCpub₂, . . . ,[ARI_(n),KS_(n)]DRCpub_(n)

In this alternate embodiment, at least k of the n KS_(i) pieces need tobe obtained to recover KS and the n DRCs 1910 are disjoint and notsubject to conspiracies of more than (k-1) parties. This splitting of KSinto shares is accomplished via any well known secret-sharing mechanism.An example of such a secret-sharing mechanism is described in A. Shamir,"How to Share a Secret", in the Communications of the ACM, vol. 22, no.11, pp. 612-613, November 1979, incorporated herein by reference in itsentirety.

Finally, since the DRF provides the encrypting user 1914 himself with aservice, there is no need to strongly enforce its correct construction.The encrypting user 1914 is not inclined to circumvent a service hedesires, uses voluntarily and possibly paid some amount of money toacquire. In addition, any refusal to decrypt (as in the first twoembodiments) based on an incorrect DRF is an inappropriate action forstorage encryption. The damage of a bad DRF is done at the time ofencryption and detection of an incorrect DRF at decryption time isineffective. Therefore, in a preferred embodiment, either no DRFverification or verification in the form of a background "sniffer" isimplemented. As further described below, a "sniffer" is a process whichrandomly selects files, checks their DRF formats (using aformat-checking service provided by the DRC 1910) and in case ofincorrect format, notifies the creator of the file (and possibly hismanager) of the flaw. This provides moderate social or administrativepressure at or shortly after encryption time to remedy a failure togenerate proper DRFs. The generation of improper DRFs can happen byaccident or oversight rather than by malicious intent.

3.2 DRF Verification

It is possible that an encrypting user 1914, without any intendedmalice, uses a version of software which doesn't attach DRFs to files(possibly because that option isn't enabled at the time), or whichmistakenly attaches (through a flaw in the software) an incorrect DRF,or which incorrectly constructs DRFs. Several options exist fordetecting such problems and minimizing the extent of the potentialdamage from them. These options (described below) include sniffing forformat, random re-building of DRFs, random verification by the DRC 1910,and doing nothing, i.e., performing no verification (the no verificationoption is discussed above). Since accessing DRFs is a very infrequentoccurrence, any time delay in detecting bad DRFs is likely to be lessthan the time until the DRF is needed, thus permitting the encryptinguser 1914 time to recreate a proper DRF.

3.2.1 Sniffing for Format

It is good practice in general to have a file "sniffer" program whichscans storage devices (such as storage device 1922), reading records andpossibly encountering bad blocks. Disk storage can go bad without beingread and a bad block is not detected until it is read. If detection isdelayed for too long after the data is written, backup copies of thatdata might also have gone bad. A "sniffer" attempts to find such blocksbefore their backup copies go bad.

A "sniffer" can operate in conjunction with the DRC 1910 by checking notonly for bad data blocks but also for bad format DRFs. This backgroundprocess should not, for security reasons, have access to the bits of theencrypted files. For example, in one embodiment, the files and the"sniffer" process could reside on a commercial file server not under thecontrol of the company or person who owns the data. The "sniffer",however, can select DRFs from files (having been modified to recognizetheir existence) and send them to their respective DRCs 1910, gettingback from the DRC 1910 a boolean answer indicating whether the DRF isencrypted properly or not. This detects improper DRF format or lack of aDRF within an encrypted file.

In an alternate embodiment, where a DRC 1910 is overwhelmed by work fromsuch "sniffing", the "sniffer" can be programmed to select apseudo-random number and use that value to control whether to verify aparticular DRF with the effect that only some percentage of the DRFsencountered are verified. That percentage can be varied to adjust thework load presented to the DRC 1910. If the DRC 1910 replies that a DRFis bad, either it or the "sniffer" (or both) could generate an audit logentry and notify the file's owner (and possibly others in the owner'smanagement chain) of the error. Maintenance of lists of persons tonotify and methods of delivering that notification are commonlyunderstood programming practices and are not described here in greaterdetail.

3.2.2 Random Re-building of DRFs

The "sniffer" cannot verify that the storage key (KS) inside a DRF isvalid because it does not have access to KS or to the private keynecessary to decrypt the DRF. If a DRF is of the form that is re-built(by using the public key algorithm to build the DRF directly, ratherthan by having the public key algorithm encrypt a secondary storage key,KS₂, which is in turn used to encrypt the DRF contents), and if theencrypting user 1914 has attached a DRF Verification String (DVS), thenthe emergency decrypting user 1916/program can verify the DRF byrebuilding it. In the event of detection of error through this process,the normal decrypting user 1916/program would generate an audit logentry and, in one embodiment, send messages (through whatever preferredmeans) to the file's owner and other in the corporate management. Unlikethe communications case of the earlier embodiments, however, it is notproper to refuse to decrypt in this circumstance. Refusal to decryptstored data implies loss of access to that data and it is preservationof access to data that the DRC 1910 is intended to provide.

Since this rebuilding is a time-consuming operation and since thepurpose of this re-building is to make the encrypting user 1914 morevigilant about the software being used, one embodiment envisions thatthe decrypting software re-builds only a randomly selected percentage ofall DRFs. It is expected that the knowledge that this re-building occursoccasionally is enough to increase encrypting user 1914 vigilance.

3.2.3 Random Verification by the DRC

In alternative embodiments, the DRF formats do not permit re-building.Even these formats, however, can be verified by the decrypting program,but the DRC 1910 must participate in the verification process. For thisreason, this DRF format might be randomly selected for verification witha much lower percentage than any other kind.

In one embodiment of verification involving the DRC 1910, the encryptinguser 1914 obtains an emergency access decryption of the file andverifies that the process works. In another embodiment, interactionbetween the encrypting user 1914 and the DRC 1910 is reduced duringverification. In this embodiment, the decrypting program, afterobtaining a storage key (KS) and decrypting the file, sends that KS andthe DRF together to the DRC 1910, asking the DRC 1910 only to decryptthe DRF and reply whether the KS that was sent and the KS inside theDRF's datum are identical.

Access rule challenge and response is not required in this case becauseas a method of gaining access to a file by an outsider, this methodamounts to a brute force key test but one in which each test involvescommunications costs and is therefore slow and not subject toimprovement with improvements in the speed of VLSI circuitry. It istherefore slower than alternate methods of attack and therefore not anincreased security risk.

3.3 Access Rules

There are two kinds of access rules (ARs) defined by the presentinvention, basic authentication tests and compound authorization rules.An AR is specified by the AR defining user 1918 who defines it and sendsit to the DRC 1910. In response, the DRC 1910 grants the AR defininguser 1918 an access rule index (ARI). The encrypting user 1914 can thenuse the ARI to include in a DRF or the AR defining user 1918 can use theARI in the definition of other ARs. This interaction between the ARdefining user 1918 and the DRC 1910 is called the registration phase andis described in greater detail below. The DRC 1910, in turn, uses an ARIto locate the associated AR and uses that rule to control challenges tothe emergency decrypting user 1916 to determine the decrypter's right toaccess.

An authentication test is an example of a relatively simple AR. If theemergency decrypting user 1916 passes the test, then the emergencydecrypting user 1916 gains access. More generally, the emergencydecrypting user 1916 receives either access or a success token, which isused to respond to other challenges. A compound authorization rule, onthe other hand, specifies a group of ARIs, some (or all) of which needto be satisfied in order for the AR to be satisfied.

3.3.1 Authentication Tests

In one embodiment, a basic authentication test includes a method forproving one's identity. In particular, it can include shared secrets(e.g., mother's maiden name), cryptographic authentication protocols,third party endorsements (e.g., verification that the person presentingdata to be validated possesses a pre-specified driver's license andmatches the picture, description and signature on that license),biometric tests (e.g., retnal scans), or any other authentication.

Additional authentication tests include multiple prompt/reply pairs. Ina multiple prompt/reply pair, an AR defining user 1918 can specify alist of N prompts and their associated replies. The AR defining user1918 also specifies the numbers A and K (K≦A≦N) such that when the DRC1910 employs the authentication test, it randomly selects A of the Nprompts to challenge the emergency decrypting user 1916. The emergencydecrypting user 1916 attempts to provide correct replies to all selectedprompts. If the emergency decrypting user 1916 gets K or more repliescorrect, the authentication test is satisfied. This variation of ashared secret test is provided for emergency decrypting users 1916 whomay have trouble remembering a particular typed string but who mightremember K of A of them with greater probability.

Finally, in a preferred embodiment of authentication by shared secret,confidentiality is provided for the reply portion. Specifically, insteadof storing the reply as a readable text string, during both registrationand responses to challenges a cryptographically strong hash of theprompt and reply is formed. This hash value is ASCII encoded and sent tothe DRC 1910 as the reply string. This confidentiality permits an ARdefining user 1918 to employ embarrassing memories as a reply on thetheory that such memories are unlikely to be either forgotten or shared.

3.3.2 Authorizadon Rules

In one embodiment, a compound authorization rule takes the form:

[n, k, ARI1, ARI2, . . . , ARIn]; k≦n

This rule is satisfied if k of the n ARIs given are satisfied. The ARsreferenced by these ARIs may be created by the AR defining user 1918 orby other persons known to the AR defining user 1918. For example, an ARcan be created to represent the authorization rule for a company'scorporate emergency access and the ARI can be listed as an optionalemergency access method for each employee.

In particular, if the corporation had a corporate ARI=c, and theemployee had an individual ARI=e, the employee could create and use anARI=u defined as u=[2, 1, e, c]. Through this definition, any file whichincluded "u" as the ARI in its DRF is available in case of emergency bysatisfying the ARI of either the employee or the corporation.

It should be noted that a group with n=k is equivalent to a logical-ANDof the group's rules thus implying that all ARIs must be satisfied.Similarly, a group with k=1 is equivalent to a logical-OR of the group'srules meaning that any one of the ARIs must be satisfied. A group withn=1 and k=1 is an ARI that indirectly references another ARI.

3.4 Use of DRC Access to Implement Data Escrow

The emergency access provided by a DRC 1910 does not take the place ofnormal access to an encrypted file. It is assumed that the normal accessto a storage key (KS) proceeds without paying attention to the DRF. Inthis situation, the normal decrypting user 1912 is the same person asthe encrypting user 1914 and has knowledge of the storage key (KS) or ofa method of obtaining KS independent of the DRC 1910. Thus, in mostcases the DRC 1910 will never know that the encrypting user 1914 haseven created the DRF for a file. However, this invention permits a newkind of storage encryption in which the storage key is chosen randomly(e.g., by the encrypting program). Consequently, in this embodiment, theonly method of access is via the emergency use of a DRF. By properdefinition of ARs, this option permits an encrypting user 1914 toimplement a data escrow mechanism in which the grantee of the data wouldhold it at all times in encrypted form, and would receive use of thatencrypted data only upon the satisfaction of a potentially complex AR.No individual person, not even the data's original encrypting user 1914,would be able to decrypt it without satisfying that AR. To implementthis option, one needs only a trusted DRC 1910 that would never releasea decrypted DRF except upon satisfaction of the corresponding AR. Inaddition to the description of a DRC 1910 below, a DRC 1910 may beencased in a tamper-resistant enclosure and have no override accessdefined. In one embodiment, the trusted DRC 1910 is highlyfault-tolerant through redundancy.

3.5 Override Access

In some embodiments, an override access is provided. Specifically, inresponse to any challenge from the DRC 1910 for satisfaction of an AR,the challenged emergency decrypting user 1916 may respond "override".The emergency decrypting user 1916 is then challenged according to anoverride AR defined for that DRC 1910. For example, the override ARcould require that 3 of 5 previously designated company officers agreeto override. The definition of such a policy is via the access rulemechanism described earlier (and further described below).

The same effect is also achieved by having the AR defining user 1918always define and use a compound authorization rule as described earlier(e.g., u=[2, 1, e, c]). However, the override mechanism saves the ARdefining user 1918 time in registration and provides a guarantee that asupervising entity (such as management) will be allowed access to allfiles, independent of any actions on the part of any employee.

3.6 Operation of the DRC

Use of the emergency access capability provided by the DRC 1910 involvesseveral separate steps:

(1) Registration,

(2) Listing of Defined ARIs,

(3) Creation of DRFs,

(4) Emergency Access Requests,

(5) Challenge-Response Protocol, and

(6) Receipt and Use of Decrypted DRF Data.

In addition to these steps, it should be noted that information to andfrom the DRC 1910 is frequently confidential and therefore, in apreferred embodiment, the implementation of the DRC 1910 includesencryption of all transactions between the DRC 1910 and the users 1916and 1918. For that purpose, the DRC's public key (DRCpub) is used tocommunicate a randomly chosen session key from the AR defining user 1918(or the emergency decrypting user 1916) to the DRC 1910. In addition,the AR defining user 1918 (or the emergency decrypting user 1916)includes inside the encrypted request to the DRC 1910, which reply keythe DRC 1910 should use for the return message. In addition toconfidentiality, there is also the question of authentication. Since anAR defining user 1918 defines himself by providing AR definitions duringregistration, there is no further AR defining user 1918 authenticationneeded for the DRC 1910/AR defining user 1918 communication.

The DRC 1910 itself, however, requires authentication by well knownpublic key methods. This is accomplished through widespread publicationof the DRC's public key using a variety of channels or signatures on theDRC's public key by a key which is either widely known or trusted (orboth). If the AR defining user 1918 uses an untrusted DRC public key,then the AR defining user 1918 is vulnerable to improper behavior by theDRC 1910 and will be unable to provide convincing evidence identifyingthat DRC 1910 for the purposes of legal remedy.

3.6.1 Registration

DRC 1910 registration (i.e., having an AR defining user 1918 registerwith a DRC 1910) involves the creation of ARs and acceptance by the ARdefining user 1918 of an access rule index (ARI) for each AR. FIG. 20illustrates generally the AR definition process between an AR defininguser 1918 and DRC 1910. In this overview, the AR definition processcomprises the following steps: (1) the AR defining user 1918 sends an ARdefinition to the DRC 1910, (2) the DRC 1910 sends a new ARI to the ARdefining user 1918, and (3) the AR defining user 1918 files the new ARIwith an optional explanatory comment in the ARI file 1920.

The ARI is a value created by the DRC that allows the DRC to locate theAR definitions corresponding to the ARI. In a preferred embodiment, theARI contains an address at which the AR definitions are stored.

The registration process is further represented by a flowchart in FIG.21. In step 2106, the AR defining user 1918 obtains a DRC public key(this step is described in Section 3.6.1.1). In step 2108, the ARdefining user 1918 chooses the desired registration interaction. These,registration interactions include the acquisition of a new DRCpub instep 2112, creating a new AR definition in step 2114, redefining anexisting AR in step 2116, and obtaining an ARI listing in step 2118. Theacquisition of a new DRCpub is described in section 3.6.1.1, thecreation of a new AR is described in sections 3.6.1.2, 3.6.1.4, 3.6.1.5and 3.6.1.6, the redefinition of an existing AR is described in section3.6.1.3, and the obtaining of an ARI listing is described in section3.6.2.

3.6.1.1 Acquisiton of DRCpub

The initial DRC public key, here labeled DRCpub(0), is available fromadvertising publications or through messages from other people. Thesecurity of further public key distribution hinges on thetrustworthiness of this initial key because public key authenticationtechniques can not establish absolute trust. Rather they can establishonly equivalency of trust.

The DRC 1910 generates new DRC public keys from time to time, in orderto minimize the volume of data which achieves emergency access under anyone key. The greater the volume that can be accessed under one key thegreater the temptation for an adversary to attempt to break thatparticular key The DRC 1910 retains all generated DRCpublic-key/private-key pairs, so that an emergency decrypting user 1916can initiate a secure communication using any of the DRCpub keys.

After a trusted DRC public key is obtained by an AR defining user 1918,the DRC 1910 returns a signed version of that DRC public key to the ARdefining user 1918 (step 2106 in FIG. 21). The most current DRC publickey is returned in every DRC 1910 interaction with any AR defining user1918 as a text block appended to the DRC's normal message. On a specialrequest by the AR defining user 1918, wherein the AR defining user 1918sends the number "i" (desired key number) and "k" (old key number), theDRC 1910 will return the new key, DRCpub(i), signed by a prior key,DRCpub(k), of the encrypter's choice.

3.6.1.2 Creation of a New Access Rule

FIG. 22 illustrates the process of creating a new AR that begins withstep 2206 where an AR defining user 1918 sends an AR definition to theDRC 1910 which records that definition. In step 2208, the DRC 1910returns an ARI to the AR defining user 1918. The AR defining user 1918receives this ARI in step 2210 and, after attaching an optionaldescriptive comment provided by the AR defining user 1918, appends theARI record to the ARI file. The ARI file already contains the DRCpub andany other ARIs which the AR defining user 1918 has already acquired.

3.6.1.3 Re-definition of an Existing Access Rule

FIG. 23 illustrates the process wherein an AR defining user 1918 desiresto change the definition of an existing AR. Although an AR defining user1918 is free to generate new ARs at will, a re-definition is requiredwhen there already exist files encrypted under a given ARI and the ARdefining user 1918 decides to change the emergency access procedure forthose existing files. To perform this redefinition, the AR defining user1918 in step 2306 sends to the DRC 1910 the new AR definition and alsothe ARI corresponding to the AR to be defined. The AR defining user 1918is then challenged by the DRC 1910 in step 2308 with the ARs attached tothe old ARI. If the AR defining user 1918 fails the challenge issued bythe DRC 1910, the redefinition request is denied in step 2110. If the ARdefining user 1918 successfully meets the challenge the AR defining user1918 is allowed to change the AR definitions for that ARI in step 2312.For the embodiment where the DRC 1910 records an AR defining user's 1914network address with each defined ARI, the request for re-definitionmust come from that network address.

3.6.1.4 Third Patty Access Rules

There are, from the AR defining user's 1914 point of view, third-partyauthentication rules built using the normal authentication tests andgroup rules. For example, an AR defining user 1918 might register withsome human-staffed service to get authentication by the AR defininguser's 1914 driver's license or any biometric measure (e.g., palm print,retnal scan, etc.). As shown in FIG. 24, that service (1) receives theAR defining user's 1914 license number (without requiring an in-personvisit) and (2) generates an AR which only the service 2404 couldsuccessfully satisfy, (3) receiving an ARI for it, in return. Theservice 2404 next (4) attaches the resulting ARI to a record of the ARdefining user's 1914 license number in the service's ARI file 2406 andthen (5) gives the resulting ARI to the AR defining user 1918. The ARdefining user 1918 would (6) make an indirect AR to that ARI (theindirect AR definition is described in more detail below), (7) get anARI for that new AR, and (8) file that ARI (now owned by the AR defininguser 1918 rather than the service 2404) in the ARI file 2408.

3.6.1.5 Definition of an Authorization (group) Rule

FIG. 25 illustrates the process of generating a group authorizationrule. First, in step 2506, an AR defining user 1918 retrieves from hisown ARI file one or more ARIs to be included in the group. The ARdefining user 1918 sends that list in a group definition to the DRC instep 2508, along with a number "K" indicating the number of groupelements that must be satisfied to satisfy the group, and receives fromthe DRC 1910 an ARI corresponding to that group in step 2510. Finally,in step 2512, the AR defining user 1918 stores the new ARI in theclient's ARI file.

3.6.1.6 Creation of an Indirect Access Rule

As shown in FIG. 26, the creation of an indirect AR proceeds similarlybut refers to someone else's ARI. In that case, the other person's 2606ARI would (1) arrive by some trusted communications channel rather thanfrom the AR defining user's 1914 own ARI file 1920. The rest of theprocess (2)-(4) is the same as the AR definition process describedabove.

3.6.2 Lisging of Defined ARIs

An AR defining user 1918 can also ask for a listing of the status of allARs defined by that AR defining user 1918. In one embodiment, theidentification of an AR defining user 1918 is by network address. Inother embodiments, it could be by way of an AR and its ARI defined onlyfor the purpose of identifying ownership of ARs or it could be whateveridentification method is normal to the network or communicationsconnection used by the DRC 1910. However, if a DRC 1910 is designed tomask network addresses, an ARI can also serve as an owner identifier. Inthis embodiment, the owner presents his identifying ARI while asking fora listing. The DRC 1910, would then challenge the owner to prove theiridentity (using the identifying ARI) and only then provide the listing.

3.6.3 Creation of DRFs

FIG. 27 illustrates a preferred embodiment of the construction of a DRF2730. In this embodiment an encrypting user's 1914 software creates aDRF 2730 by concatenating an ARI 2706 (selected by the encrypting user1914, depending on which AR the encrypting user 1914 wants to use) andsome small User's Secret [US] 2708. The US 2708 is often (but notlimited to) a key for the symmetric encryption for a file (i.e., KS),but can be any data which the encrypting user 1914 wants to encrypt.This concatenation is called the DRF contents (DRFC) 2714. The DRFC 2714is then encrypted using a DRCpub resulting in the Encrypted DRFC (EDRFC)2722. The EDRFC 2722 is concatenated with the Key Identifier (KI) 2712that uniquely identifies the DRCpub used to make the EDRFC 2722. In apreferred embodiment, the KI 2712 comprises a network address for theDRC [DRC ID] 2702 concatenated with a DRCpub key number 2704. An exampleof this KI 2712 is "drc@tis.com,4".

3.6.4 Emergency Access Requests

When an emergency decrypting user 1916 needs to decrypt a file whosestorage key (KS) is available inside a DRF and the normal access to KSfails, he can use the DRF attached to the file. More generally, wheneverthe emergency decrypting user 1916 needs whatever small secret (i.e., US2708) is held inside the DRF, the emergency decrypting user 1916 canissue an emergency access request to the DRC 1910.

FIG. 28 illustrates the method of obtaining emergency access. First, instep 2806, the emergency decrypting user 1916 extracts from the storagemedium 1922 the DRF that is attached to the file of interest (or the DRFalone if that is what is of interest) and then, in step 2808, sends theextracted DRF to the DRC 1910. In step 2810, the DRC 1910 issues achallenge defined by the AR definition for the ARI in the extracted DRF.

FIG. 31 illustrates the processing steps performed by DRC 1910 inissuing the challenge to the emergency decrypting user 1916. First, instep 3106, the DRC 1910 uses the KI 2712 to identify DRCpub thenretrieves, in step 3108, the DRC private key corresponding to thatparticular DRCpub. In step 3110, the DRC 1910 decrypts EDRFC 2722 toobtain DRFC 2714 and retrieves the ARI 2706 from the DRFC 2714 in step3112. Finally, the DRC 1910, in step 3114, uses ARI 2706 to locate thecorresponding AR (e.g., AR residing at the address ARI) and challengesthe emergency decrypting user 1916 in step 3116.

Referring again to FIG. 28, if the emergency decrypting user 1916 failsto meet the challenge in step 2812, emergency access is denied in step2814. If the emergency decrypting user 1916 meets the challenge in step2812, the DRC 1910 sends the DRFC 2714 to the emergency decrypting user1916 in step 2816. The emergency decrypting user 1916 receives the DRFC2714 in step 2818 and extracts the US 2708 from the DRFC 2714 in step2820.

In one embodiment, steps 2806 and 2820 are performed by the softwarewhich initially created the file and the DRF. In this embodiment, thelocation of the DRF within or alongside the file (or database record, orwhatever item is encrypted) is under the control of some applicationsoftware rather than the DRC 1910 or its encrypting user 1914.

In one embodiment, steps 2808 through 2818 are performed by theemergency-decrypting user's 1916 software, to provide an easy, seamlessinterface to the DRC 1910. In a preferred embodiment, the emergencydecrypting user's 1916 software writes the DRF to a file in step 2806and retrieves the DRFC from a file in step 2820, allowing steps 2808through 2814 to be performed by a separate application which is purely aDRC client.

According to one embodiment, steps 2808 and 2818 involve well knownmethods for providing secure transmission of information. The preferredembodiment uses symmetric encryption with a session key chosen at randomby the emergency decrypting user 1916. That key is encrypted in DRCpuband communicated (along with a KI 2712 to identify the key used) to theDRC 1910 along with the encrypted message. That message includes acommand to the DRC 1910 to use a given (randomly chosen) key forcommunications back to the emergency decrypting user 1916 in step 2818.In this manner, the emergency decrypting user 1916 does not need tocreate a public key for key transmission purposes.

3.6.5 Challenge-Response Protocol

The process of responding to challenges mirrors the nested structure ofthe relevant AR definition. FIG. 29 shows the challenge-response cycle.In step 2906, the DRC 1910 issues a challenge (which can be thought ofas a remote-procedure-call [RPC]) and the AR defining user 1918 oremergency decrypting user 1916 responds to that challenge in step 2908.FIG. 30 shows this cycle as it pertains to an emergency access request.

If the ARI identifies an AR representing a simple authentication test,then the emergency decrypting user 1916 has all of the information toprovide the correct response. However, if the ARI specifies an ARrepresenting a group or indirect AR, then the emergency decrypting user1916 needs to perform non-local work in order to get the correctresponse. This non-local work will involve further nested RPCs. If theARI specifies an indirection, then the RPC is from one emergencydecrypting user 1916 to another emergency decrypting user 1916. Invarious situations, the RPC could involve network communication ormerely the hand-carrying of data on a floppy disk (e.g., if theindirection is for the purpose of physical authentication).

For every challenge issued by the DRC 1910, the DRC 1910 includes aSequence token (SEQ). The SEQ is an encrypted datum which only the DRC1910 can decrypt and which includes the recursive stack of challengesalong with the transaction number and a strong checksum on the contentsof the SEQ (to detect tampering). For example, if ARI=17 specifies agroup of which ARI=5 is a member, the first Sequence token will list arecursion depth of 1 and the set [17] as the stack. The emergencydecrypting user 1916 is then challenged with a group challenge thatlists the members of the group. The decrypting user 1916 chooses one ofthese to satisfy first, for example 5, and recursively calls the DRC1910 to challenge the emergency decrypting user 1916 to satisfy ARI=5.That recursive call includes the SEQ which the DRC 1910 provided withthe group challenge. When the DRC 1910 performs the recursive RPC,calling the emergency decrypting user 1916 to satisfy ARI=5, that callwill include a SEQ listing a recursion depth of 2 and a stack of [17,5].

In a preferred embodiment, there are two conditions under which the DRC1910 issues a challenge to a emergency decrypting user 1916. In thefirst condition, the emergency decrypting user 1916 submits a DRF 2730for emergency access. This submission includes no other information andstarts a new transaction. If this challenge gets a correct response, theDRC 2730 returns the DRFC 2714.

In the second condition, the emergency decrypting user 1916 submits arequest to be challenged as part of fulfilling a group or indirection.This submission includes a SEQ identifying the transaction and recursivestack of which this recursive challenge is a part. The emergencydecrypting user 1916 submitting that request need not be the sameemergency decrypting user 1916 who submitted the DRF 2730 which startedthis transaction. If this challenge gets a correct response, the DRC1910 returns a SUCCESS token which includes the same information as theSEQ along with the fact of success.

In response to a simple challenge (a prompt/reply or a digitalsignature, for example), the emergency decrypting user 1916 replies withthe SEQ and the correct response. In return, the DRC 1910 provideseither the DRFC 2714 or a SUCCESS token.

In response to a group or indirect challenge, the emergency decryptinguser 1916 provides one or more SUCCESS tokens which the DRC 1910verifies as being part of this transaction and as correctly satisfyingthe group or indirect AR. In return, the DRC 1910 provides either theDRFC 2714 or a SUCCESS token.

In addition, in a preferred embodiment, to keep from having either theDRC 1910 or the emergency decrypting user 1916 maintain state (i.e., thecontents of all variables which will be used by the computer programissuing the RPC between getting the answer from the RPC and returning tothe program's caller) across RPCs, the DRC 1910 includes a state tokenwith every RPC it initiates and the emergency decrypting user 1916includes a state token with every RPC it initiates. The responder to theRPC returns that token, if any, with its response. Those tokens areencrypted in a key known only to the originator and include informationto permit the originator to verify that the token goes with the SEQ withwhich it is accompanied.

As a result, the state of the DRC 1910 and emergency decrypting user1916 are maintained over this recursive set of RPCs in which theidentity of the caller keeps changing hands.

3.6.6 Receipt and Use of the DRFC

As mentioned above, the successful completion of an emergency accessrequest is the return of a DRFC 2714 to the emergency decrypting user1916. The purpose of the challenge-response is to verify that theemergency decrypting user 1916 making the request is authorized toreceive the DRFC 2714. Since the DRFC 2714 comprises an ARI 2706 by theAR defining user 1918, any subsequent emergency decrypting user 1916 whocan satisfy that AR 2706 has, presumably, been granted authority by theAR defining user 1918 to have access.

Once the DRFC 2714 is returned to the emergency decrypting user 1916,the emergency decrypting user's 1916 software has the responsibility forusing the DRFC 2714 to provide access to the file (i.e., for extractingthe US 2708 from the DRFC 2714, and perhaps for using the US 2708 todecrypt other data). Again, it should be noted that in otherapplications, the DRFC 2714 itself could be the information desired(e.g., a safe combination). In this case there is nothing extensiveneeded in the software which receives the DRFC 2714.

While various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample only, and not limitation. Thus, the breadth and scope of thepresent invention should not be limited by any of the above-describedexemplary embodiments, but should be defined only in accordance with thefollowing claims and their equivalents.

What is claimed is:
 1. A system for controlling access by an emergencydecrypting system to a user secret, the system comprising:first meansfor retrieving at least part of a user secret; second means forretrieving at least one access rule index, said at least one access ruleindex identifying an access rule, stored in a corresponding datarecovery center that controls access by an emergency decrypting systemto said at least part of said user secret, wherein an access ruleincludes an authentication test or a compound authorization rule; andmeans for generating a data recovery field using said at least part ofsaid user secret, said at least one access rule index and a datarecovery center public key, wherein emergency decryption comprisesdecryption using a data recovery field.
 2. The system of claim 1,wherein said means for generating generates a data recovery field thatincludes an encryption of a concatenation of said user secret and saidaccess rule index using said data recovery center public key.
 3. Thesystem of claim 2, wherein said means for generating generates a datarecovery field that includes a concatenation of said encryption and akey identifier, wherein said key identifier comprises a data recoverycenter identifier and a data recovery center public key number.
 4. Thesystem of claim 1, wherein said first means generates a plurality ofparts of said user secret,wherein said second means retrieves aplurality of access rule indexes, each of said plurality of access ruleindexes identifying one or more access rules, stored in a correspondingone of a plurality of data recovery centers, that control access by anemergency decrypting system to said plurality of parts of said usersecret; and wherein said means for generating generates a plurality ofdata recovery fields using said plurality of parts of said user secret,said plurality of access rule indexes, and a plurality of data recoverycenter public keys corresponding to said plurality of data recoverycenters.
 5. The system of claim 4, wherein said means for generatinggenerates a plurality of data recovery fields, each data recovery fieldincluding an encryption of a concatenation of a part of said user secretand an access rule index using a data recovery center public key.
 6. Thesystem of claim 5, wherein said means for generating generates aplurality of data recovery fields, each data recovery field in saidplurality of data recovery fields including a concatenation of anencryption of a part of said user secret and an access rule index usinga data recovery center public key, and a key identifier, wherein saidkey identifier comprises a data recovery center identifier and a datarecovery center public key number.
 7. The system of claim 1, furthercomprising:means for generating a data recovery field verificationstring, said data recovery field verification string includinginformation that enables an entity to authenticate said data recoveryfield.
 8. The system of claim 1, wherein said access rule indexreferences an authentication test that verifies a user's identity. 9.The system of claim 1, wherein said authentication test includes one ofa shared secret, cryptographic authentication protocols, third partyendorsements, and biometric tests.
 10. The system of claim 1, whereinsaid access rule index references an access rule that comprises Nprompt/reply pairs, wherein the numbers A and K (K≦A≦N) are specifiedsuch that said access rule is satisfied if an entity correctly respondsto K of the A prompt/reply pairs that said data recovery center randomlyselects.
 11. The system of claim 1, wherein said access rule indexreferences an access rule of the form [n, k, ARI1, ARI2, . . . , ARIn],k≦n, such that said access rule is satisfied if k of the n access ruleindexes are satisfied.
 12. The system of claim 1, wherein said at leastone access rule index is an address that references an access rule. 13.The system of claim 6, wherein said user secret is an encryption key.14. The system of claim 13, further comprising:means for attaching saiddata recovery field to a message encrypted with said encryption key. 15.A method for controlling access by an emergency decrypting system to auser secret, the method comprising the steps of:(1) retrieving at leastpart of a user secret; (2) retrieving at least one access rule index,said at least one access rule index identifying an access rule, storedin a corresponding data recovery center that controls access by anemergency decrypting system to said at least part of said user secret,wherein an access rule includes an authentication test or a compoundauthorization rule; and (3) generating a data recovery field using saidat least part of said user secret, said at least one access rule indexand a data recovery center public key, wherein emergency decryptioncomprises decryption using a data recovery field.
 16. The method ofclaim 15, wherein step (3) comprises the step of generating a datarecovery field that includes an encryption of a concatenation of saiduser secret and said access rule index using said data recovery centerpublic key.
 17. The method of claim 16, wherein step (3) comprises thestep of generating a data recovery field that includes a concatenationof said encryption and a key identifier, wherein said key identifiercomprises a data recovery center identifier and a data recovery centerpublic key number.
 18. The method of claim 15, wherein step (1)comprises the step of generating a plurality of parts of said usersecret,wherein step (2) comprises the step of retrieving a plurality ofaccess rule indexes, each of said plurality of access rule indexesidentifying one or more access rules, stored in a corresponding one of aplurality of data recovery centers, that control access by an emergencydecrypting system to said plurality of parts of said user secret; andwherein step (3) comprises the step of generating a plurality of datarecovery fields using said plurality of parts of said user secret, saidplurality of access rule indexes, and a plurality of data recoverycenter public keys corresponding to said plurality of data recoverycenters.
 19. The method of claim 18, wherein step (3) comprises the stepof generating a plurality of data recovery fields, each data recoveryfield including an encryption of a concatenation of a part of said usersecret and an access rule index using a data recovery center public key.20. The method of claim 19, wherein step (3) comprises the step ofgenerating a plurality of data recovery fields, each data recovery fieldin said plurality of data recovery fields including a concatenation ofan encryption of a part of said user secret and an access rule indexusing a data recovery center public key, and a key identifier, whereinsaid key identifier comprises a data recovery center identifier and adata recovery center public key number.
 21. The method of claim 15,further comprising the step of:generating a data recovery fieldverification string, said data recovery field verification stringincluding information that enables an entity to authenticate said datarecovery field.
 22. The method of claim 19, wherein step (2) comprisesthe step of retrieving at least one access rule index, said at least oneaccess rule index identifying an access rule, stored in a correspondingdata recovery center, that controls access by an emergency decryptingsystem to said at least part of said user secret, wherein said accessrule index references an authentication test that verifies a user'sidentity.
 23. The method of claim 18, wherein step (2) comprises thestep of retrieving at least one access rule index, said at least oneaccess rule index identifying an access rule, stored in a correspondingdata recovery center, that controls access by an emergency decryptingsystem to said at least part of said user secret, wherein said accessrule index references an authentication test that includes one of ashared secret, cryptographic authentication protocols, third partyendorsements, and biometric tests.
 24. The method of claim 19, whereinstep (2) comprises the step of retrieving at least one access ruleindex, said at least one access rule index identifying an access rule,stored in a corresponding data recovery center, that controls access byan emergency decrypting system to said at least part of said usersecret, wherein said access rule index references an access rule thatcomprises N prompt/reply pairs, wherein an access rule defining systemspecifies the numbers A and K (K≦A≦N) such that said access rule issatisfied if an entity correctly responds to K of the A prompt/replypairs that said data recovery center randomly selects.
 25. The method ofclaim 19, wherein step (2) comprises the step of retrieving at least oneaccess rule index, said at least one access rule index identifying anaccess rule, stored in a corresponding data recovery center, thatcontrols access by an emergency decrypting system to said at least partof said user secret, wherein said access rule index references an accessrule of the form [n, k, ARI1, ARI2, . . . , ARIn], k≦n, such that saidaccess rule is satisfied if k of the n access rule indexes aresatisfied.
 26. The method of claim 19, wherein step (2) comprises thestep of retrieving at least one access rule index, said at least oneaccess rule index identifying an access rule, stored in a correspondingdata recovery center, that controls access by an emergency decryptingsystem to said at least part of said user secret, wherein said at leastone access rule index is an address that references an access rule. 27.The method of claim 19, wherein step (1) comprises the step ofretrieving at least part of an encryption key.
 28. The method of claim27, further comprising the step of attaching said data recovery field toa message encrypted with said encryption key.
 29. A computer programproduct, comprising:a computer usable medium having computer readableprogram code means embodied in said medium for implementing a method ofcontrolling access by an emergency decrypting system to a user secret,said computer readable program code means comprising computer readablefirst program code means for enabling a computer to effect a retrievalof at least part of a user secret; computer readable second program codemeans for enabling a computer to effect a retrieval of at least oneaccess rule index, said at least one access rule index identifying anaccess rule, stored in a corresponding data recovery center thatcontrols access by an emergency decrypting system to said at least partof said user secret, wherein an access rule includes an authenticationtest or a compound authorization rule; and computer readable thirdprogram code means for enabling a computer to effect a generation of adata recovery field using said at least part of said user secret, saidat least one access rule index and a data recovery center public key,wherein emergency decryption comprises decryption using a data recoveryfield.
 30. The computer program product of claim 29, wherein saidcomputer readable third program code means enables a computer to effecta generation of a data recovery field, said data recovery fieldincluding an encryption of a concatenation of said user secret and saidaccess rule index using said data recovery center public key.
 31. Thecomputer program product of claim 30, wherein said computer readablethird program code means enables a computer to effect a generation of adata recovery field, said data recovery field including a concatenationof said encryption and a key identifier, wherein said key identifiercomprises a data recovery center identifier and a data recovery centerpublic key number.
 32. The computer program product of claim 29, whereinsaid computer readable first program code means enables a computer toeffect a creation of a plurality of parts of said user secret,whereinsaid computer readable second program code means enables a computer toeffect a retrieval of a plurality of access rule indexes, said pluralityof access rule indexes identifying a plurality of access rules, storedin a corresponding plurality of data recovery centers, that controlaccess by an emergency decrypting system to said plurality of parts ofsaid user secret; and wherein said computer readable third program codemeans enables a computer to effect a generation of a plurality of datarecovery fields using said plurality of parts of said user secret, saidplurality of access rule indexes, and a plurality of data recoverycenter public keys corresponding to said plurality of data recoverycenters.
 33. The computer program product of claim 32, wherein saidcomputer readable third program code means enables a computer to effecta generation of a plurality of data recovery fields, each data recoveryfield in said plurality of data recovery fields including an encryptionof a concatenation of a part of said user secret and an access ruleindex using a data recovery center public key.
 34. The computer programproduct of claim 33, wherein said computer readable third program codemeans enables a computer to effect a generation of a plurality of datarecovery fields, each data recovery field in said plurality of datarecovery fields including a concatenation of (1) an encryption of a partof said user secret and an access rule index using a data recoverycenter public key, and (2) a key identifier, wherein said key identifiercomprises a data recovery center identifier and a data recovery centerpublic key number.
 35. The computer program product of claim 29, furthercomprising:computer readable program code means that enables a computerto effect a generation of a data recovery field verification string,said data recovery field verification string including information thatenables an entity to authenticate said data recover field.
 36. Thecomputer program product of claim 29, wherein said access rule indexreferences an authentication test that verifies a user's identity. 37.The computer program product of claim 29, wherein said authenticationtest includes one of a shared secret, cryptographic authenticationprotocols, third party endorsements, and biometric tests.
 38. Thecomputer program product of claim 29, wherein said access rule indexreferences an access rule that comprises N prompt/reply pairs, whereinthe numbers A and K (K≦A≦N) are specified such that said access rule issatisfied if an entity correctly responds to K of the A prompt/replypairs that said data recovery center randomly selects.
 39. The computerprogram product of claim 29, wherein said access rule index referencesan access rule of the form [n, k, ARI1, ARI2, . . . , ARIn], k≦n, suchth at said access rule is satisfied if k of the n access rule indexesare satisfied.
 40. The computer program product of claim 29, whereinsaid at least one access rule index is an address that references anaccess rule.
 41. The computer program product of claim 29, wherein saiduser secret is an encryption key.
 42. The computer program product ofclaim 41, further comprising:computer readable program code means thatenables a computer to effect an attachment of said data recovery fieldto a message encrypted with said encryption key.